\pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\f0\b0\i0\ulnone\fs28\fc0\cf0 Q: I've made connections in InterfaceBuilder like I have a zillion times before. So, why are all of my outlets nil when I run my program?\
\
A:
\fc1\cf1 In earlier releases, you had to provide a method to set each outlet that you declared in a new class. For example, if your subclass had an outlet named
\b myOutlet
\b0 , the source code for your subclass had to declare and implement this method:\
\
\f1\fs22 - setMyOutlet:anObject\
\{\
myOutlet = anObject;\
return self;\
\}\
\
\f0\fs28 In InterfaceBuilder, the Unparse command in the Classes window's pop-up list would create these "set" methods automatically. \
\
These outlet initialization methods are no longer required. However, for backward compatibility, if an object responds to such a message, the runtime system uses them to initialize outlets. Basically, the runtime system does this:\
\f2\fs24 \
\f1\fs22 if ([yourObject respondsTo:@selector(setMyOutlet:)])\
setMyOutlet:anObject\
\f0\fs28 \
All is hunky dory, if you remember the days when these methods were required. Now that InterfaceBuilder does not generate them automatically, it is not obvious that these method names have special meaning. So, if you have a method name
\b setMyOutlet
\b0 you must set the outlet within that method. If you don't initialize the outlet, then
\b myOutlet
\b0 is nil at runtime.\
\
Overall it is best to avoid
\b setMyOutlet
\b0 style method names altogether, unless you are consciously taking advantage of this "feature," and are doing
\pard\tx1800\tx2160\tx2520\fc1\cf1 additional initialization within the "set" method.
\pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc1\cf1 Care must be taken, as the order in which outlets and other objects are initialized is neither guaranteed nor predictable.
